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La presente inven JPconcerne un procede de chargemenfll changements 
de plannings de vol dans un systeme de reservation de transports a6riens par 
ordinateurs. 

Les changements de plannings dans de tels systemes necessitent des 
manipulations fort importantes sur la base de donnees de plannings existante. 

Un planning de vol decrit la facon dont le reseau aerien est emprunte par les 
avions. Les plannings sont calcules dans le but d'optimiser les connexions entre les 
vols, I'usage des avions et I'occupation des places. Les changements a apporter a 
un planning existant sont de ce fait generalement des changements non isoles qui 
ont un impact possible sur des correspondences avec d'autres operations de vol. 

Actuellement, les plannings de vol sont sujets a de plus en plus de 
reorganisation compte tenu de la concurrence accrue, la necessite d'entente entre 
les compagnies aeriennes et la sophistication des moyens informatiques utilises pour 
etablir les plannings. 

Usuellement, les compagnies aeriennes appliquent les changements d/e 
planning les uns apres les autres. Lors de ces changements, la personne chargee 
d'appliquer les changements n'a aucune connaissance quant aux reservations de 
place existantes sur les vols qu'il est en train de modifier. 

Le systeme d'inventaire des reservations aeriennes applique les 
changements a la base de donnees des plannings sans pour autant etre capable 
d'apprehender, de fagon globale, le nombre de changements et de modifications que 
cela entraTne. 

Le precede actuellement utilise consistant a appliquer les uns apres les 
autres les changements de plannings a un premier inconvenient qui consiste dans le 
fait que les reservations deja operees sont generalement changees plus souvent que 
necessaire. Cette situation arrive notamment si les passagers sont deplaces vers un 
autre vol et que ce dernier est sujet, par la suite, a un changement. Dans ce dernier 
cas, il faut encore modifier !a reservation du passager. 

Les changements des reservations de passagers sont coQteux car ils 
impliquent une intervention manuelle de la part des agents de voyage, des coGts de 
reseau et de traitement informatique. 

Un autre inconvenient des procedes actuellement mis en ceuvre est que les 
importants changements a apporter a une base de donnees existante de plannings 




La pr6sent^nnvention concerne un precede c^^hargement de 

changements de plannings de vol dans un syst£me de reservation de 
transports aeriens par ordinateurs. 

Les changements de planninjgs dans de tels systemes necessitent des 
5 manipulations fort importantes sur la base de donnees d^plannings existante. "~ 
Un planning de vol decrit la faQon dont le reseau aerien est emprunte 
par les avions. Les plannings sont calcules dans le but d'optimiser les 
connexions entre les vols, Pusage des avions et I'occupation des places. Les 
changements 3 apporter & un planning existant sont de ce fait gen^ralement 
10 des changements non isoies qui ont un impact possible sur des 
correspondances avec d'autres operations de vol. 

Actuellement, les plannings de vol sont sujets a de plus en plus de 
reorganisation compte tenu de la concurrence accrue, la necessity d'entente 
entre les compagnies aeriennes et la sophistication des moyens informatiques 
15 utilises pour etablir les plannings. 

Usuellement, les compagnies aeriennes appliquent les changements de 
planning les uns apres les autres. Lors de ces changements, la personne 
chargee d'appliquer les changements n'a aucune connaissance quant aux 
reservations de place existantes sur les vols qu'il est en train de modifier. 
20 Le systeme dlnventaire des reservations aeriennes applique les 

changements a la base de donnees des plannings sans pour autant §tre 
capable d'appr^hender, de fagon globale, le nombre de changements et de 
modifications que cela entraTne. 

Le proc§d6 actuellement utilise consistant a appliquer les uns apres les 
25 autres les changements de plannings a un premier inconvenient qui consiste 
dans le fait que les reservations deja operees sont generatement changees plus 
souvent que necessaire. Gette situation arrive notartimeht si les passagers sont 
deplaces vers un autre vol et que ce dernier est sujet, par la suite, a un 
changement. Dans ce dernier cas, il faut encore modifier la reservation du 
30 passager. 

Les changements des reservations de passagers sont couteux car ils 
impliquent une intervention manuelle de la part des agents de voyage, des 
couts de reseau et de traitement informatique. 



peuvent prendre un templ^ortant puisque Ies repercussions sfts reservations 
des passagers doivent etre analysees manuellement et au cas par cas. 

L'objet de Invention est d'apporter une solution au probleme des 
modifications de planning de vol dans un systeme de reservation de transports 
aeriens par ordinateur. 

Elle propose, pour y parvenir, un nouveau procede dans lequel on met a jour 
la base de donnees de planning de vol et on reaffecte Ies reservations concernees 
par Ies changements de planning de vol pour la mise a jour de la base de donnees 
d'inventaire de reservation, de fagon particuliere. 

Un premier avantage de I'invention est de traiter une pluralite de 
changements de planning de vol de fagon globale, ce qui permet d'envisager des 
reaffectations de reservation de passagers en tenant compte de I'integralite de ces 
changements, quel que soit I'ordre des changements dans le fichier de modification 
de planning. 

Par ailleurs, selon I'invention, Ies changements de plannings sont appliques 
par I'intermediaire d'une simulation sans activation definitive, ce qui evite Ies risques 
de perturbation de la base de donnees existante avant complete finalisation et 
validation de la mise a jour. 

Pour fournir un choix global dans la reaffectation des reservations des 
passagers, I'invention permet au serveur d'acceder a la fois a la base de donnees 
existante et a de nouveaux enregistrements correspondants au futur planning qu'il 
conviendra d'appliquer. 

On notera que Ies gains d'efficacite de I'invention sont particulierement 
importants, notamment compte tenu du caractere generalement massif des 
modifications de planning a operer. 

A titre d'exernple, on peut distinguer differents types de procedures de 
changement de plannings : 

- Ies changements saisonniers qui presentent des changements de plannings 
massifs variant en taille de 2000 a 8000 lignes et qui necessitent generalement une 
validation au niveau de plusieurs instances de ('organisation de gestion du systeme 
de reservation de transports aeriens par ordinateur, 

- Ies reajustements. Generalement, il s'agit de modifications affectant des 
vols a une date proche du depart et pour lesquelles la reaffectation des reservations 
est particulierement importante et necessite une consideration particuliere. 
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Un autre inconvenient des proc6des actuellement^PI en oeuvre est 
que les importants changements & apporter a une base de donnees existante 
de plannings peuvent prendre un temps important puisque les repercussions 
sur les reservations des passagers doivent etre analysees manuellement et au 
5 cas par cas. 

L'objet de i'invention est d'apporter une solution au probleme des 
modifications de planning de vol dans un systeme de reservation de transports 
aeriehs par ordinateur. 

Elle propose, pour y parvenir, un nouveau procede dans lequel on met 
10 a jour la base de donnees de planning de vol et on reaffecte les reservations 
concernees par les changements de planning de vol pour la mise a jour de la 
base de donnees d'inventaire de reservation, de fagon particuliere. 

Un premier avantage de Tinventibn est de traiter une pluralite de 
changements de planning de vol de fagon globale, ce qui permet d'envisager 
15 des reaffectations de reservation de passagers en tenant compte de I'integralite 
de ces changements, quel que sort I'ordre des changements dans le fichier de 
modification de planning. 

Par ailleurs, selon I'invention, les changements de plannings sont 
appliques par Prntermediaire d'une simulation sans activation definitive, ce qui 
20 evite les risques de perturbation de la base de donnees existante avant 
complete finalisation et validation de la mise a jour. 

Pour foumir un choix global dans la reaffectation des reservations des 
passagers, Tinvention permet au serveur d'acceder a la fois a la base de 
donnees existante et a de nouveaux enregistrements correspondents au futur 
25 planning qu'il conviendra d'appliquer. 

On notera que les gains d'efficacite de {'invention sont particulierement 
importants, notamment compte tenu du caractere geh6ralement massif des 
modifications de planning a operer. 

A titre d'exemple, on peut distinguer differents types de procedures de 
30 changement de plannings : 

- les changements saisoriniers qui presentent des changements de 
plannings massifs variant en taille de 2000 a 8000 lignes et qui necessitent 
generalement une validation au niveau de piusieurs instances de I'organisation 
de gestion du systeme de reservation de transports aeriens par ordinateur, 
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- les changemenw^eguliers qui peuvent etre operd^oe facon fort 
automatique compte tenu de leur nature. 

La presente invention permet le chargement de tels changements quelle que 
soit leur nature et permet egalement de gerer un ensemble de parametres 
d'automatisation des mises a jour a effectuer. 

Dans ce cadre, on pourra aisement ajuster le niveau de controle manuel a 
operer pour les changements a prendre en compte. 

D'autres buts et avantages apparaltront au cours de la description qui suit 
d'un mode de realisation prefere de ('invention qui n'en n'est cependant pas limitatif. 

La presente invention concerne un precede de chargement de changements 
de plannings de vol dans un systeme de reservation de transports aeriens par 
ordinateur, dans lequel : 

- on met a jour la base de donn6es de plannings de vol ; 

- on reaffecte les reservations concernees par les changements de plannings 
de vol pour la mise a jour de la base de donnees d'inventaire de reservations, 

caracterise par le fait qu'il comporte les etapes suivantes : 

reception d'au moins un lot de changements contenant des donnees 
de changement de plannings de vols, 

extraction des changements individuels contenus dans le lot et/ 
stockage dans un registre comme enregistrements de planning futur * 
simulation de reaffectation des reservations concernees par les 
changements de plannings, par acces du serveur de distribution des 
reservations a la fois aux enregistrements et a la base de donnees de 
plannings de vol, 

mise a jour definitive des bases de donnees de plannings de vol et 
d'inventaire des reservations. 
Ce precede se presente avantageusement suivant les variantes enoncees ci- 
apres et selon lesquelles : 

- on utilise une interface utilisateur graphique pour la verification des 
changements extraits du lot de changements. 

- on utilise une interface utilisateur graphique pour la validation des 
reaffectations de reservation. 

- on affecte un suffixe (SL) caracteristique aux changements a stacker comme 
enregistrements de planning futur (FSR). 





itions affectant 



des vols a une date proche du depart et pour lesquelles la reaffectation des 
reservations est particulierement importante et nScessite une consideration 
particuliere. 

5 - les changernents reguliers qui peuvent etre oplfes de fagon fort 

automatique compte tenu de leur nature. 

La presente invention permet !e chargement de tels changernents 
quelle que soit leur nature et permet §galement de gerer un ensemble de 
parametres d'automatisation des mises a jour a effectuer. 
10 Dans ce cadre, on pourra ais6ment ajuster le niveau de controle 

manuel a operer pour les changernents a prendre en compte. 

D'autres buts et avantages apparaTtront au cours de la description qui 
suit d'un mode de realisation pr§f6re de Tinvention qui n'en n'est cependant pas 
limitatif. 

15 La presente invention conceme un procede de chargement de 

changernents de plannings de vol dans un systeme de reservation de 
transports aeriens par ordinateur, dans lequel : 



20 plannings de vol pour la mise a jour de la base de donnees dMnventaire de 
reservations, 



- on met a jour la base de donnees de plannings de vol ; 

- on r6affecte les reservations concernees par les changernents de 



caracterise par le fait qu'il comporte les stapes suivantes : 



reception d'au moins un lot de changernents contenant des 
donnees de changement de plannings de vols, 
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extraction des changernents tndividuels contenus dans le lot et 
stockage dans un registre comme enregistrements de planning 
futur 
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simulation de reaffectation des reservations concernees par les 
changernents de plannings, par acces du serveur de distribution 
des reservations 3 la fois aux enregistrements et a la base de 
donnees de plannings de vol, 



mise a jour definitive des bases de donnees de plannings de vol 
et d'inventaire des reservations. 



- on affecte a chaqftnregistrement (FSR) un argument ^ is published) 
indiquant si cet enregistrement (FSR) est rendu accessible au serveur de distribution 
de reservation. 

- pour chaque changement extrait : 

on ouvre les periodes de vol de la base de donnees de plannings de 
vol affectees par le changement ; 

si ladite periode n'a pas deja ete affectee par un changement dont 

('argument (FSR is published) est positif, on duplique ladite periode et 

on affecte le suffixe (SL) a la periode dupliquee ; 

on envoie un message de changement de planning pour integrer le 

changement dans la periode dupliquee qu'il affecte ; 

on indique que le changement est un enregistrement accessible au 

serveur de distribution des reservations en mettant son argument 

(FSR is published) a I'etat positif. 

- lors de la simulation de reaffectation, on met a jour les dependences entre 
enregistrements sachant qu'un enregistrement A depend d'un enregistrement B si et 1 
seulement si la reaffectation des passagers lors de Implication de I'enregistrement A 
se fait vers le futur planning decrit dans I'enregistrement B. 

- en cas de dependance cyclique entre plusieurs enregistrements, lors de 
I'execution des operations de reaffectation dans le systeme de reservation, on ne 
modifie qu'une fois et une seule chaque reservation concernee par I'ensemble des 
ces reaffectations. 

- on supprime les enregistrements (FSR) apres mise a jour definitive des 
bases de donnees de plannings de vol et d'inventaire des reservations. 

Les dessins ci-joints sont donnes a titre d'exemples et ne sont pas limitatifs 
de Invention, lis represented seulement un mode de realisation de 1'invention et 
permettront de la comprendre aisement. 

La figure 1 illustre schematiquement la configuration de differents moyens 
informatiques aptes a etre utilises pour mettre en oeuvre I'invention. 

Les figures 2 et 3 sont des blocs diagrammes de diverses etapes 
successives de la presente invention. 

En se referant a la figure 1, on a illustre que le precede ici presente peut 
utiliser un serveur de changement de planning SLS apte a recevoir un lot de taches 
de changement de plannings a operer. En outre, ce serveur de changement SLS est 



e^fe pr^sente avantageusement su^^t 



Ce proc£de^e presente avantageusement su^pt les variantes 
enoncees ci-apres et selon lesquelles : 

- on utilise une interface utilisateur graphique pour la verification des 
changements extraits du lot de changements. 

5 V on utilise une interface utilisateu des 

reaffectations de reservation. 

- on affecte un suffixe (SL) caracteristique aux changements a stocker 
comme enregistrements de planning futur (FSR)- 

- on affecte a chaque enregistrement (FSR) un argument (FSR is 
10 published) indiquant si cet enregistrement (FSR) est rendu accessible au 

serveur de distribution de reservation. 

- pour chaque changement extrait : 

on ouvre les periodes de vol de la base de donnees de 
planriings de vol affectees par le changement ; 

is - si ladite periode n'a pas deja ete affectee par un changement 

dont rargument (FSR is published) est positif, on duplique ladite 
periode et on affecte le suffixe (SL) a la periode dupliquee ; 
on envoie un message de changement de planning pour integrer 
le changement dans la periode dupliquee qu'il affecte ; 

20 - on indique que le changement est un enregistrement accessible 

au serveur de distribution des reservations en mettant son 
argument (FSR is published) a I'etat positif. 

- lors de ta simulation de reaffectation, on met a jour les dependances 
entre enregistrements sachant qu'un enregistrement A depend d'un 

25 enregistrement B si et seulement si la reaffectation des passagers lors de 
Tapplication de Tenregistrement A se fait vers le futur planning d6crit dans 
Tenregistrement B. 

- en cas de dependance cyclique entre plusieurs enregistrements, lors de 
('execution des operations de reaffectation dans le systeme de reservation, on 

30 ne modifie qu'une fois et une seule chaque reservation concernee par 
Tensemble des ces reaffectations. 

- on supprime les enregistrements (FSR) apres mise a jour definitive des 
bases de donnees de plannings de vol et dinventaire des reservations. 



accessible a un utilisateur '^in analyste ou un supervisee par I'irlBmediaire d'une 
interface utilisateur graphique GUI en particulier pour la verification des changements 
extraits du fichier de changement constitutif du lot de taches de changement et pour 
la validation des reaffectations de reservations. 

Une partie des etapes du precede de I'invention peut par ailleurs etre mise 
en oeuvre dans la partie de distribution du systeme de reservation au niveau du 
serveur de distribution CS et de la base de donnees existante db1 comprenant la 
base de donnees d'inventaire des reservations et la base de donnees de plannings 
de vols. 

Au niveau du serveur de changement de planning SLS, a I'arrivee d'un lot de 
changements, II est possible dans un premier temps, de verifier I'integrite des 
changements et des eventuels problemes de conflit, de tester les regies 
d'automatisation et de rendre les donnees accessibles par I'intermediaire de 
rinterface utilisateur graphique GUI. 

A ce stade, differents criteres d'automatisation pourront etre affectes a 
chacun des lots de changements a operer. En particulier, les criteres 
d'automatisation concernent I'automatisation des changements de plannings et 
I'automatisation des reaffectations de reservations. Selon la valeur de ces : 
parametres, les changements peuvent etre traites de facon manuelle ou automatique 1 
ou encore presenter certaines etapes manuelles et certaines etapes automatiques. 

A titre prefere, des intervenants analystes precedent a une etape de 
validation selon les parametres de traitement et d'automatisation qui ont ete prevus. 

Eventuellement, un superviseur peut egalement operer une verification a la 
suite. Ces etapes de validation qui debouchent sur une signature des analystes et du 
superviseur sont representees en figure 2. 

A Tissue de ces etapes, il est possible de produire des enregistrements de 
plannings futurs qui pourront etre utilises par le systeme central au niveau du serveur 
de distribution CS. A cet effet, on stocke dans un registre les differents changements 
extraits du lot de changements recu sous forme d'enregistrements de plannings 
futurs FSR. 

Les enregistrements de plannings futurs FSR sont rendus accessibles par le 
serveur de distribution CS sous forme de publication. On decrit une possibility de 
procedure prevue a cet effet : 
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Les dessinsflooints sont donnes a titre d'exemp^^t ne sont pas 
limitatifs de invention, lis represented seulement un mode de realisation de 
I'invention et permettront de la comprendre aisement. 

La figure 1 illustre schematiquement la configuration de differents 
5 moyens informatiques aptes a etre utilises pour mettre en oeuvre I'invention. 

Les figures 2 et 3 sont des blocs diagrammes de diverses etapes 
successives de la presente invention. 

En se referant a la figure 1, on a illustre que le procede ici presente 
peut utiliser un serveur de changement de planning SLS apte a recevoir un lot 
10 de taches de changement de plannings a operer. En outre, ce serveur de 
changement SLS est accessible a un utilisateur tel un analyste ou un 
superviseur par I'intermediaire d'une interface utilisateur graphique GUI en 
particulier pour la verification des changements extraits du fichier de 
changement constitutif du lot de taches de changement et pour la validation des 
15 reaffectations de reservations. 

Une partie des etapes du procede de I'invention peut par ailleurs etre 
mise en oeuvre dans la partie de distribution du systeme de reservation au 
niveau du serveur de distribution CS et de la base de donnees existante db1 
comprenant la base de donnees d'inventaire des reservations et la base de 
20 donn§es de plannings de vols. 

Au niveau du serveur de changement de planning SLS, £ I'arrivee d'un 
lot de changements, il est possible dans un premier temps, de verifier Tintegfite 
des changements et des eventuels problemes de confl'rt, de. tester les regies 
d'automatisation et de rendre les donnees accessibles par I'intermediaire de 
25 1'interface utilisateur graphique GUI. 

A ce stade, differents criteres d'automatisation pourront etre affectes a 
chacun des lots de changements a op6rer. En particulier, les criteres 
d'automatisation concernent Tautomatisation des changements de plannings et 
Tautomatisation des r§affectations de reservations. Selon ia valeur de Ges 
30 parametres, les changements peuvent etre traites de fagon manuelle ou 
automatique ou encore presenter certaines etapes manuelles et certaines 
§tapes automatiques. 




on commencf^ar determiner la liste des changemfll de plannings 
qui doivent etre publies comme enregistrements de plannings futurs 
FSR. De cette facon, on supprime tous les changements qui n'ont pas 
d'impact sur les reaffectations de reservations, en particulier des 
changements qui ne concernent que des mises a jour de service telle 
la fourniture de repas a bord des avions. 

pour chacun des changements de plannings de la liste, on opere de la 
facon suivante : 

on affecte a chaque enregistrement FSR un suffixe SL qui permet de 
le caracteriser comme enregistrement de planning futur FSR par 
rapport aux autres donnees accessibies par le serveur de distribution 
CS, 

on affecte a chaque enregistrement FSR un argument, par exemple 
denomme « FSR is published » indiquant si cet enregistrement FSR 
a ete rendu accessible au serveur de distribution des reservations ' 
CS ou non. Si I'argument « FSR is published » est vrai, c'est que 
I'enregistrement FSR est accessible, 

on releve, dans le planning existant, les periodes de vol qui sont 
concernees par le changement en question. 

pour chacune de ces periodes concernees, on recherche si elle est 
deja concernee par un changement de planning qui aurait un 
argument « FSR is published » place a I'etat vrai. Si ce n'est pas le 
cas, on duplique cette periode en y affectant le suffixe SL. Si 
I'argument « FSR is published » est deja vrai pour un changement 
precedent, c'est que cette periode a deja ete dupliquee. A ce stade, 
le systeme central dispose done d'un double du planning courant 
avec les suffixes SL. 

on envoi alors un message de changement de planning pour les 
donnees disposant du suffixe SL, ce message decrivant comment le 
planning futur doit etre. Le systeme central dispose alors de 
plannings futurs parfaitement decrits dans les periodes considerees 
affectees du suffixe SL. 

pour ce changement de planning, I'argument « FSR is published » 
est place a I'etat vrai. 



A titre prefereTdes intervenants analystes procedl^Pa une etape de 
validation selon les parametres de traitement et d'automatisation qui ont ete 
prevus. 

Eventuellement, un superviseur peut egalement operer une verification 
a la surteT Ces etapes de \^ndatSon~qui dibouchent sur urie'sighature des 
analystes et du superviseur sont representees en figure 2. 

A Tissue de ces etapes, il est possible de produire des enregistrements 
de plannings futurs qui pourront etre utilises par le systeme central au niveau 
du serveur de distribution CS. A cet effet, on stocke dans un registre les 
differents changements extraits du lot de changements recu sous forme 
d'eriregistrernents de plannings futurs FSR. 

Les enregistrements de plannings futurs FSR sont rendus accessibles 
par le serveur de distribution CS sous forme de publication. On decrit une 
possibility de procedure prevue a cet effet : 

on commence par determiner la liste des changements de 
plannings qui doivent etre publies comme enregistrements de 
plannings futurs FSR. De cette facon, on supprime tous les 
changements qui n'ont pas d'impact sur les reaffectations de 
reservations, en particulier des changements qui ne concernent 
que des mises a jour de service telle la fourniture de repas a 
bord des avions. 

pour chacun des changements de plannings de la liste, on opere 
de la fagon suivante : 

on affecte a chaque enreglstrement FSR un suffixe SL qui 
permet de le caracteriser comme enregistrement de planning 
futur FSR par rapport aux autres donnees accessibles par le 
serveur de distribution CS, 

on affecte a chaque enregistrement FSR un argument, par 
exemple denomme « FSR is published » indiquant si cet 
enregistrement FSR a ete rendu accessible au serveur de 
distribution des reservations CS ou non. Si I'argument « FSR is 
published » est vrai, c'est que I'enregistrement FSR est 
accessible, 



On latere ensuiPces differentes operations pour^nsemble des 

changements de plannings contenus dans le lot jusqu'a ce quite aient tous un 
argument « FSR is published » place a I'etat vrai. 

A la suite de ces etapes, le systeme central, et particulierement le serveur de 
distribution CS, est capable d'acceder aux enregistrements de plannings futurs FSR 
afin de trouver les meilleures alternatives de vol lors des reaffectations de 
reservation. 

C'est cette etape qui est ensuite operee. 

Elle sera decrite ci-apres plus en detail dans un mode prefere de realisation. 

Lorsqu'elle est terminee et que la mise a jour des bases de donnees est 
definitive, il sera possible d'effacer les enregistrements de plannings futurs FSR. 

On decrit maintenant plus precisement les etapes de simulation de la 
reaffectation des reservations qui precedent la mise a jour definitive des bases de 
donnees de plannings de vol et de reservation. 

Le systeme de reservation choisit automatiquement une option de' 
reaffectation (pour chaque changement de planning le necessitant). Cette option est 
choisie parmi les plannings futurs FSR ou les plannings courants (pour les vols non 
concernes par le lot eri cours). 

Une fois les options de reaffectations automatiquement evaluees, le systeme ' 
les verifie grace aux regies d'automatisation des reaffectations. Les reaffectations ne 
satisfaisant pas ces regies sont soumises a une validation par un operateur (qui peut 
alors modifier les options calculees automatiquement par le systeme). 

Lorsque toutes les reaffectations ont ete validees, ('application proprement 
dite du lot de changements dans le systeme de reservation peut commencer. 

A cet effet, il faut d'abord noter que la reaffectation de passagers pose des 
problemes de dependance entre les vols. On entend par dependence entre deux 
changements de plannings la necessity pour operer un changement (S1 par 
exemple) concernant un vol F1 de reaffecter certains passagers du vol F1 vers un 
futur planning S2 concernant un vol F2. 

Par ailleurs, on peut rencontrer des questions de dependance cyclique dans 
lesquelles la dependance des vols est reciproque. 

Dans ce contexte (par exemple supposons 2 changements de planning S1 et 
S2 concernant les vols F1 et F2 impliquant la reaffectation des reservations de F1 
vers le futur planning de F2 et la reaffectation des reservations de F2 vers le futur 



o on refeve, dans le planning existant, les pBfcdes de vol qui 

sont concernees par le changement en question. 
° pour chacune de ces periodes concernees, on recherche si elle 
est deja concernee par un changement de planning qui aurait 
5 un argument « FSR is published » place a r§taTvraL Si ce ri'est" 

pas le cas, on duplique cette periode en y affectant le suffixe 
SL. Si I'argument « FSR is published » est deja vrai pour un 
changement precedent, c'est que cette periode a deja ete 
dupliquee. A ce stade, le systeme central dispose done d'un 
10 double du planning courant avec les suffixes SL. 

b on envoi alors un message de changement de planning pour 
les donnees xlisposant du suffixe SL, ce message decrivant 
comment le planning futur doit etre. Le systeme central dispose 
alors de plarinings futurs parfaitement decrits dans les periodes 
is consider£es affectees du suffixe SL. 

* pour ce changement de planning, I'argument « FSR is 
published » est plac6 a fetat vrai. 
On reitere ensuite ces differentes operations pour Tensemble des 
changements de plannings contenus dans le lot jusqu'a ce qu'ils aient tous un 
20 argument « FSR is published » plac6 a I'etat vrai. 

A la suite de ces etapes, le systeme central, et particulierement le 
serveur de distribution CS, est capable d'acceder aux enregistrements de 
plannings futurs FSR afin de trouver les meilleures alternatives de vol lors des 
r6affectations de reservation. 
25 C'est cette etape qui est ensuite op£ree. 

Elle sera decrite ci-apres plus en detail dans un mode prefere de 
realisation. 

Lorsqu'elle est termin§e et que la mise a jour des bases de donnees est 
definitive, il sera possible d'effacer les enregistrements de plannings futurs 
30 FSR. 

On d6crit maintenant plus precisement les etapes de simulation de la 
reaffectation des reservations qui precedent la mise a jour definitive des bases 
de donnees de plannings de vol etde reservation. 
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planning de F1), II convienRs de I'execution des reaffectations Ml le systeme de 
reservation, de ne modifier chaque reservation qu'une fois et une seule dans le 
contexte d'un lot de changements de planning (afin d'eviter dans notre exemple que 
des passages ne soient reaffectes vers le planning futur de F2 puis de nouveau vers 
le futur planning de F1). 

Lors de ('execution du lot de changements de planning, la base de donnees 
des plannings et d'abord mise a jour. 

Le systeme alloue ensuite un identifiant I'operation « I » unique caracterisant 
le lot en cours. Le systeme de reservation regoit alors I'ensemble des instructions de 
reaffectations ainsi que I'identifiant d'operation « I ». II doit alors garantir I'unicite de 
modification de chaque reservation dans le contexte de I'operation « I ». 

Un mode prefere de realisation de cette contrainte consiste pour chaque 
modification de reservation a : 

verifier que cette reservation ne possede pas la marque « I », 
modifier dans ce cas la reservation 

marquer ensuite ia reservation modifiee avec I'identifiant « I ». 
Au fur et a mesure des reaffectations, la base de donnees d'inventaire est 
egalement mise a jour. 

Les trois bases de donnees (inventaire, reservation et planning) sont alors a' 
jour et les enregistrements FSR peuvent etre supprimes. 



Le systeme^re reservation choisit automatiquerri^p une option de 
reaffectation (pour chaque changement de planning le necessitant). Cette 
option est choisie parmi les plannings futurs FSR ou les plannings courants 
(pour les vols non concerned par le lot en cours). 

Unefolsles'opti^^ evalueesrle 
systeme les verifie grace aux regies d'automatisatlon des reaffectations. Les 
reaffectations ne satisfaisant pas ces regies sonf soumises a une validation par 
un operateur (qui peut alors modifier les options calculees automatiquement par 
le systeme). 

Lorsque toutes les reaffectations ont ete validees, I'application 
proprement dite du lot de changements dans le systeme de reservation peut 
commencer. 

A cet effet, il faut d'abord noter que la reaffectation de passagers pose 
des problemes de dependance entre les vols. On entend par dependance entre 
deux changements de plannings la necessite, pour operer un changement (S1 
par exemple) concernant un vol F1 de reaffecter certains passagers du vol F1 
vers un futur planning S2 concernant un vol F2. 

Par ailleurs, on peut rencontrer des questions de dependance cyclique 
dans lesquelles la dependance des vols est reciproque. 

Dans ce contexte (par exemple supposons 2 changements de planning 
S1 et S2 concernant les vols F1 et F2 impliquant la reaffectation des 
reservations de F1 vers le futur planning de F2 et la reaffectation des 
reservations de F2 vers le futur planning de Fi), il convient, lors de I'execution 
des reaffectations dans le systeme de reservation, de ne modifier chaque 
reservation qu'une fois et une seule dans le contexte d'un lot de changements 
de planning (afin d'eviter dans notre exemple que des passages ne soient 
reaffectes vers le planning futur de F2 puis de nouveau vers le futur planning de 
F1). 

Lors de I'execution du lot de changements de planning, la base de 
donnees des plannings et d'abord mise a jour. 

Le systeme alloue ensuite un identifiant ('operation « I » unique 
caracterisant le lot en cours. Le systeme de reservation recoit alors Tensemble 
des instructions de reaffectations ainsi que I'identifiant d'operation « I ». II doit 
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SLS : serveur de changement de planning 
CS : serveur de distribution 
db1 : base de donnees existante 
GUI : interface utilisateur graphique 



alors garantir runicfPte modification de chaque reservations le contexte 

de I'operation « I ». 

Un mode prefere de realisation de cette contrainte consiste pour 

chaque modification de. reservation a : 

verifier que cette reservation ne poss&de pas fa marque « i », 
modifier dans ce cas la reservation 

marquer ensuite la reservation modifiee avec I'identifiant « I ». 
Au fur et a mesure des reaffectations, la base de donnees d'inventaire 

est egalement mise a jour. 

Les trois bases de donnees (inventaire, reservation et planning) sont 
alors a jour et les enregistrements FSR peuvent etre supprimes. 
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SLS : serveur de changement de planning 
CS : serveur de distribution 
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GUI : interface utilisateurgraphique 



1. Procede de chargement de changements de plannings de vol dans un 
systeme de reservation de transports aerienspar ordinateur, dans lequel : 

- on met a jour la base de donnees de plannings de vol ; 

- on reaffecte les reservations concernees par les changements de plannings 
de vol pour la mise a jour de la base de donnees d'inventaire de reservations, 

caracterise par le fait qu'il comporte les etapes suivantes : 

reception d'au moins un lot de changements contenant des donnees 
de changement de plannings de vols, 

extraction du lot de changement des changements qu'il contient et 
stockage dans un registre comme enregistrements de planning futur 
(FSR) 

simulation de reaffectation des reservations concernees par les 
changements de plannings, par acces du serveur de distribution des 
reservations a la fois aux enregistrements (FSR) et a la base de 
donnees de plannings de vol, 

mise a jour definitive des bases de donnees de plannings de vol et 
d'inventaire des reservations. 

2. Procede selon la revendication 1 caracterise par le fait 

qu'on utilise une interface utilisateur graphique pour la verification des 
changements extraits du lot de changements. 

3. Procede selon la revendication 1 ou la revendication 2 caracterise par le fait 
qu'on utilise une interface utilisateur graphique pour la validation des 

reaffectations de reservation. 

4. Procede selon I'une quelconque des revendications 1 a 3 caracterise par le 

fait 

qu'on affecte un suffixe (SL) caracteristique aux changements a stacker 
comme enregistrements de planning futur (FSR). 

5. Procede selon I'une quelconque des revendications 1 a 4 caracterise par le 

fait 

qu'on affecte a chaque enregistrement (FSR) un argument (FSR is published) 
indiquant si cet enregistrement (FSR) est rendu accessible au serveur de distribution 
de reservation. 
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o. rroceae seion les revendications 4 et 5 en combinaisonTaracterise par le 
fait que 

pour chaque changement extrait : 

on ouvre les periodes de vol de la base de donnees de plannings de 
vol affectees par le changement ; 

si ladite periode n'a pas deja ete affectee par un changement dont 

I'argument (FSR is published) est positif, on duplique ladite periode et 

on affecte le suffixe (SL) a la periode dupliquee ; 

on envoie un message de changement de planning pour integrer le 

changement dans la periode dupliquee qu'il affecte ; 

on indique que le changement est un enregistrement accessible au 

serveur de distribution des reservations en mettant son argument 

(FSR is published) a I'etat positif. 

7. Procede selon I'une quelconque des revendications 1 a 6 caracterise par le 
fait que 

lors de la simulation de reaffectation, on attribue a chaque enregistrement un 
degre de dependance fonction du nombre d'autres enregistrements en cascade pour 
lesquels une application dudit enregistrement entraTne une reaffectation des 
reservations sur lesdits autres enregistrements. 

8. Procede selon la revendication 7 caracterise par le fait 

qu'en cas de dependance cyclique entre plusieurs enregistrements, lors de 
('execution des operations de reaffectation dans le systeme de reservation, on ne 
modifie qu^une fois et une seule chaque reservation concernee par I'ensemble des 
ces reaffectations. 

9. Procede selon I'une quelconque des revendications 1 a 8 caracterise par le 



fait 



qu'on supprime les enregistrements (FSR) apres mise a jour definitive des 
bases de donnees de pfennings de vol et d'inventaire des reservations. 




* 

REVENDICATIONS 

1. Procede de chargement de donnees relatives a des changements de 
planni nas de vo l dans un ^ a _ 6 [ iens _? a I 
ordlnateur, dans lequel : 

- on met a jour la base de donnees de plannings de vol ; 

- on reaffecte les reservations concemees par les changements de 
plannings de vol pour la mise a jour de la base de donnees d'inventaire de 
reservations, 

caracterise par le fait qu'il comporte les etapes suivantes : 

reception d'au moins un lot de changements contenant des 
donnees de changement de plannings de vols, 
extraction du lot de changement des changements qu'il contient 
et stockage dans un registre comme enregistrements de 
planning futur (FSR) 

mise en relation du registre d'enregistrement de planning futur 
(FSR) et du serveur de distribution des reservations, 
simulation de reaffectation des reservations concernees par les 
changements de plannings, par acces du serveur de distribution 
des reservations a la fois aux enregistrements (FSR) et a la 
base de donnees de plannings de vol, 

mise a jour definitive des bases de donnees de plannings de vol 
et d'inventaire des reservations. 

2. Precede selon la revendication 1 caracterise par le fait 

qu'on utilise une interface utilisateur graphique pour la verification des 
changements extraits du lot de changements. 

3. Procede selon la revendication 1 ou la revendication 2 caracterise par 

le fait 

qu'on utilise une interface utilisateur graphique pour la validation des 
reaffectations de reservation. 

4. Procede selon I'une quelconque des revendications 1 a 3 caracterise 

par le fait 

qu'on affecte un sufflxe (SL) caracteristique aux changements a stacker 
comme enregistrements de planning futur (FSR). 
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5. Procede sefbn I'une quelconque des revendicatJn^l a 4 caracterise 
par le fait 

qu'on affecte a chaque enregistrement (FSR) un argument (FSR is 
published) indiquant si cet enregistrement (FSR) est rendu accessible au 
serveur de distribution de reservation. 

6. Procede selon les revendications 4 et 5 en combinaison caracterise 
par le fait que 

pour chaque changement extrait : 

on ouvre les periodes de vol de la base de donnees de 

plannings de vol affectees par le changement ; 

si ladite periode n'a pas deja ete affectee par un changement 

dont I'argument (FSR is published) est positif, on duplique ladite 

periode et on affecte le suffixe (SL) a la periode dupliquee ; 

on envoie un message de changement de planning pour integrer 

le changement dans la periode dupliquee qu'il affecte ; 

on indique que le changement est un enregistrement accessible 

au serveur de distribution des reservations en mettant son 

argument (FSR is published) a I'etat positif. 

7. Procede selon I'une quelconque des revendications 1 a 6 caracterise 
par le fait que 

lors de la simulation de reaffectation, on attribue a chaque 
enregistrement un degre de dependance fonction du nombre d'autres 
enregistrements en cascade pour lesquels une application dudit enregistrement 
entraTne une reaffectation des reservations sur lesdits autres enregistrements. 

8. Procede selon la revendication 7 caracterise par le fait 

qu'en cas de dependance cyclique entre plusieurs enregistrements, lors 
de I'execution des operations de reaffectation dans le systeme de reservation, 
on ne modifie qu'une fois et une seule chaque reservation concernee par 
Pensemble des ces reaffectations. 

9. Procede selon I'une quelconque des revendications 1 a 8 caracterise 
par le fait 

qu'on supprime les enregistrements (FSR) apres mise a jour definitive 
des bases de donnees de plannings de vol et d'inventaire des reservations. 
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